Dirty dancing

Dirty Stream : quand une application Android peut écraser les fichiers d’une autre

Dirty Stream agite le Net depuis quelques jours. Il faut dire que cette « faille » fait les gros titres à coups de milliards de smartphones Android touchés. Suivant comment les applications sont programmées, elles peuvent se laisser berner par un pirate qui peut écraser des fichiers pour en prendre le contrôle. Inutile de paniquer pour autant, des correctifs sont déployés.

La semaine dernière, Microsoft a publié un billet de blog pour présenter Dirty Stream, présenté comme un « modèle de vulnérabilité courant dans les applications Android ». Les risques sont réels puisque cela peut aller jusqu’à l’exécution de code arbitraire et au vol de jetons d’identification, deux situations très dangereuses.

Avant de paniquer, un point important : Microsoft a prévenu les développeurs bien en avance afin de pouvoir corriger le tir. C’est notamment le cas des applications de gestionnaire de fichier de Xiaomi et WPS Office. Elles ont été mises à jour dès le mois de février, bien avant la publication de ce bulletin d’alerte. Microsoft s’est également rapproché de Google, qui a mis en ligne une page sur son site dédié aux développeurs Android (et une autre ici) afin de prévenir les développeurs et leur proposer des protections à mettre en place.

Content Provider : gare à l’implémentation

Mais de quoi s’agit-il exactement ? Microsoft commence par un rappel sur le fonctionnement du système d’exploitation : « Android impose l’isolation en attribuant à chaque application son propre espace dédié pour le stockage des données et la mémoire. Pour faciliter le partage des données et des fichiers, Android propose un composant appelé Content Provider, qui agit comme une interface pour gérer et exposer les données aux autres applications, de manière sécurisée ».

Utilisé correctement, le Content Provider est décrit par Microsoft comme « une solution fiable ». Mais, comme souvent, une implémentation « inappropriée peut introduire des vulnérabilités qui pourraient permettre de contourner les restrictions de lecture/écriture dans le répertoire personnel d’une application ».

On est donc face à un cas malheureusement assez classique où il faut distinguer le protocole ou la fonctionnalité de son implémentation (c’est-à-dire sa mise en œuvre de manière pratique) dans les applications. Comme on a pu le voir par le passé (ici et encore ici ou … et ce n’est que la partie visible de l’iceberg), il peut y avoir une grande différence entre les deux.

On vous épargne le fonctionnement précis du Content Provider (détaillé ici par Google), mais il arrive que des applications « ne valident pas le contenu du fichier qu’elle reçoive et, ce qui est le plus inquiétant, utilisent le nom de fichier fourni » par l’application qui envoie les données. Ce fichier est alors stocké dans le répertoire de données interne de l’application ciblée. Voyez-vous venir le risque ?

Remplacer des fichiers par ceux des pirates

Avec des noms de fichier taillés sur mesure, l’application d’un pirate peut donc remplacer les fichiers clés de l’application cible et ainsi en prendre le contrôle. Dans tous les cas, l’impact varie en fonction des applications et de leur mise en œuvre.

« Par exemple, il est très courant que les applications Android lisent les paramètres de leur serveur à partir du répertoire shared_prefs. Dans de tels cas, l’application malveillante peut écraser ces paramètres, ce qui l’oblige à communiquer avec un serveur contrôlé par l’attaquant et à envoyer les jetons d’identification de l’utilisateur ou d’autres informations sensibles », explique Microsoft. Ce serait un peu comme si une application pouvait venir remplacer n’importe quel fichier sur votre ordinateur…

Microsoft en ajoute une couche : « Dans le pire des cas (et ce n’est pas si rare), l’application vulnérable peut charger des bibliothèques natives à partir de son répertoire de données dédié (par opposition au répertoire /data/app-lib, plus sécurisé, où les bibliothèques sont protégées contre toute modification). Dans ce cas, l’application malveillante peut écraser une bibliothèque avec du code malveillant, qui est alors exécuté lors du chargement ».

Dans le cas du gestionnaire de fichier de Xiaomi, cette technique a permis d’exécuter du code « arbitraire avec l’ID utilisateur et les autorisations du gestionnaire de fichiers ». On vous laisse imaginer le boulevard que cela ouvre au pirate, qui peut ainsi contrôler l’application et accéder à l’ensemble des fichiers ou presque.

Google confirme et donne des « astuces »

Google confirme les risques sur cette page : « Si un pirate informatique parvient à écraser les fichiers d'une application, cela peut entraîner l'exécution de code malveillant (en écrasant le code de l'application) ou sinon, permettre la modification du comportement de l'application (par exemple, en écrasant les préférences partagées de l'application ou d'autres fichiers de configuration) ».

Au-delà des applications mises à jour, d’autres peuvent encore être vulnérables. Microsoft et Google proposent donc des méthodes pour éviter de tomber dans ce piège.

« La solution la plus sûre consiste à ignorer complètement le nom renvoyé par l’application lors de la mise en cache du contenu. Certaines des approches les plus robustes que nous avons rencontrées utilisent des noms générés aléatoirement, de sorte que, même dans le cas où le contenu d’un flux entrant est mal formé, il n’altère pas l’application ». Une autre solution serait d’enregistrer les fichiers dans un répertoire dédié.

Mille milliards de mille sabords

Terminons avec un mot sur l’emballement autour de cette affaire. On entend souvent parler de milliards de terminaux affectés, ce n’est pas aussi simple. Microsoft explique avoir « identifié plusieurs applications vulnérables dans le Google Play Store qui représentaient plus de quatre milliards d'installations ». Quatre milliards d’installations (dont plus d’un milliard pour la seule application de Xiaomi) ne signifie pas que quatre milliards de smartphones sont touchés, loin de là.

La question est aussi de savoir si on doit parler d‘une mauvaise gestion des données du côté des développeurs qui laissent des données de leur application se faire écraser par des fichiers externes, ou bien d’une faille d’Android qui laisse ce genre d’action passer, peu importe ce qu’en disent les applications.

Commentaires (5)


-snip-

J'espère que la suite de l'article clarifie ce bordel. Elle le fait. :yes:

"Inutile de paniquer pour autant, des correctifs sont déployés."

On parle bien d'Android, hein ?

"cela peut aller jusqu’à l’exécution de code arbitraire et au vol de jetons d’identification, deux situations très dangereuses."

Le titre a du oublier ça.

Au passage un hors sujet, je viens de me rendre compte que les sous titres sont au dessus des titres, perso j'aime pas.

"On vous épargne le fonctionnement précis du Content Provider (détaillé ici par Google), mais il arrive que des applications « ne valident pas le contenu du fichier qu’elle reçoive et, ce qui est le plus inquiétant, utilisent le nom de fichier fourni » par l’application qui envoie les données. Ce fichier est alors stocké dans le répertoire de données interne de l’application ciblée. Voyez-vous venir le risque ? "

Je crois que oui, mais l'appli qui envoie peut envoyer à une appli qui n'a rien demandé ?
Modifié le 06/05/2024 à 16h41

Historique des modifications :

Posté le 06/05/2024 à 16h39


"Suivant comment les applications sont programmées, elles peuvent se laisser berner par un pirate qui peut écraser des fichiers pour en prendre le contrôle."

J'ai pas compris.
C'est pour écraser quels fichiers ? Ceux des applications bernées ? Mais le titre parle d'écraser des fichiers d'une autre application. Autre que celle bernée ?
C'est pour prendre le contrôle des fichiers écrasés ? L'intérêt pour le pirate m'échappe.

J'espère que la suite de l'article clarifie ce bordel.

"Inutile de paniquer pour autant, des correctifs sont déployés."

On parle bien d'Android, hein ?

"cela peut aller jusqu’à l’exécution de code arbitraire et au vol de jetons d’identification, deux situations très dangereuses."

Le titre a du oublier ça.

Au passage un hors sujet, je viens de me rendre compte que les sous titres sont au dessus des titres, perso j'aime pas.

"On vous épargne le fonctionnement précis du Content Provider (détaillé ici par Google), mais il arrive que des applications « ne valident pas le contenu du fichier qu’elle reçoive et, ce qui est le plus inquiétant, utilisent le nom de fichier fourni » par l’application qui envoie les données. Ce fichier est alors stocké dans le répertoire de données interne de l’application ciblée. Voyez-vous venir le risque ? "

Je crois que oui, mais l'appli qui envoie peut envoyer à une appli qui n'a rien demandé ?

Les anciens Android ne sont plus si oubliés que ça. Si tu ne reçois plus de MaJ de l'OS, à cause de Google ou plutôt du constructeur de ton smartphone, ce n'est pas si dramatique que ça laisse le supposer. En effet, depuis pas mal de versions d'Android, des composants clef ont été migré vers le système PlayStore. Cela signifie que les mises à jour passent par GooglePlay, et plus par les grosses mises à jour de l'OS, cela même quand ces dernières ne sont plus disponibles. Les MaJ d'OS, c'est principalement pour corriger des failles de sécu spécifiques, comme par ex la dernière faille Bluetooth, ou encore des correctifs de stabilité, ou enfin fournir (dans de très rares cas, la faute à la frilosité et/ou à l'immobilisme des constructeurs) de nouveaux pilotes.

Reste que le problème évoqué par l'article est délicat à aborder. Comme cela a été dit, est-ce qqchose à corriger sur les applis, ou bien un modèle de programmation à revoir côté OS ? Un peu des deux en fait. Android a toujours été un système très (trop ?) brouillon dans ses API, mais les devs ont leur part de responsabilité quand ils ne testent pas bien leurs applis, ou lorsqu'ils ne cherchent pas assez à maîtriser les APIs qu'ils utilisent.
Enfin bon, le nombre d'applis impactées ne devrait pas non plus être dramatique. On peut dormir sur nos deux oreilles, quand bien même nombre de sites de news en font leur beurre et nous pondent des titres putaclics.
Lis le billet de Microsoft, il est assez long mais explique bien.

Pour répondre à ta dernière question : il faut que l'appli à qui on envoie ait dit accepter des données et des fichiers venant d'autres applications.
Ils listent les types d'appli qui font souvent ça :
Common application categories that can be share targets include mail clients, social networking apps, messaging apps, file editors, browsers, and so on.


Et quand tu charges un fichier, Android te demande à quelle appli tu veux envoyer le fichier mais une appli malveillante peut préciser directement une appli sans te demander pour l'attaquer.
Il aurait été appréciable que l'article décrive l'attaque et non pas que la vulnérabilité. Si certaines applis ouvrent un fichier façonné alors le piratage peut avoir lieu. D'accord, mais comment ce fichier arrive ? Parce que quelqu'un nous l'envoi ? Parce qu'on le transfert dans son téléphone ? Ou bien une appli tierce malveillante à qui on aurait donné suffisamment de permission est capable de le créer ? Ce n'est pas clair. La surface et le vecteur d'attaque ne sont pas bien décrits.
C'est une appli tierce malveillante qui peut le faire créer par une autre appli. Je ne suis pas sûr qu'elle ait besoin de beaucoup de droits.

Comme je l'ai conseillé plus haut, lis le billet de blog de Microsoft pour plus de détails.
Fermer